## 3.11. Options

>     Options option  option ...
>     Default: All
>     Server config, virtual host, directory, .htaccess

The `Options` directive is unusually multipurpose and does not fit into any one site or strategic context, so we had better look at it on its own. It gives the webmaster some far-reaching control over what people get up to on their own sites.

`All`

  All options are enabled except `MultiViews` (for historical reasons), `IncludesNOEXEC`, and `SymLinksIfOwnerMatch` (but the latter is redundant if `FollowSymLinks` is enabled).

`ExecCGI`

  Execution of CGI scripts is permitted -- and impossible if this is not set.

  The server follows symbolic links (i.e., file links made with the Unix `ln` `-s` utility); server-side includes are permitted (see Chapter 10, "Server-Side Includes").

`FollowSymLinks`

  See next section.

`Includes`

  Server-side includes are permitted -- and impossible if this is not set.

`IncludesNOEXEC`

  Server-side includes are permitted, but `#exec` and `#include` of CGI scripts are disabled.

`Indexes`

  If the customer requests a URL that maps to a directory, and there is no index.html there, this option allows the suite of indexing commands to be used, and a formatted listing is returned (see Chapter 7, "Indexing" ).

`MultiViews`

  Content-negotiated `MultiViews` are supported. This includes `AddLanguage` and image negotiation (see Chapter 6, "MIME, Content and Language Negotiation").

`SymLinksIfOwnerMatch`

  Symbolic links are followed and lead to files or directories owned by the same user (see next section).

The arguments can be preceded by "+" or "-", in which case they are added or removed. The following command, for example, adds `Indexes` but removes `ExecCGI`:

>     Options +Indexes -ExecCGI

If no options are set, and there is no `<Limit>` directive, the effect is as if `All` had been set, which means, of course, that `MultiViews` is not set. If any options are set, `All` is turned off. This has at least one odd effect: if you have an ... /htdocs directory without an index.html and a very simple Config file, and you access the site, you see a directory of ... /htdocs. For example:

>     User Webuser
>     Group Webgroup
>     ServerName www.butterthlies.com
>     DocumentRoot /usr/www/site.ownindex/htdocs

If you add the line:

>     Options ExecCGI

and access it again, you see the following rather baffling message:

>     FORBIDDEN
>     You don't have permission to access / on this server

The reason is that when `Options` is not mentioned, it is, by default, set to `All`. By switching `ExecCGI` on, you switch all the others off, including `Indexes`. The cure for the problem is to edit the Config file so that the new line reads:

>     Options +ExecCGI

Similarly, if "+" or "-" are not used and multiple options could apply to a directory, the last most specific one is taken. For example:

>     Options ExecCGI
>     Options Indexes

results in only `Indexes` being set, which might surprise you. The same effect can arise through multiple `<Directory>` blocks:

>     <Directory /web/docs>
>     Options Indexes FollowSymLinks
>     </Directory>
>     <Directory /web/docs/specs>
>     Options Includes
>     </Directory>

Only `Includes` is set for /web/docs/specs.

### 3.11.1. FollowSymLinks, SymLinksIfOwnerMatch

When we saved disk space for our multiple copies of the Butterthlies catalogs by keeping the images bench.jpg, hen.jpg, bath.jpg, and tree.jpg in /usr/www/main_docs and making links to them, we used hard links. This is not always the best idea, because if someone deletes the file you have linked to and then recreates it, you stay linked to the old version with a hard link. With a soft, or symbolic, link, you link to the new version. To make one, use `ln` `-s` `source_filename destination_filename`.

However, there are security problems to do with other users on the same system. Imagine that one of them is a dubious character called Fred, who has his own webspace, ... /fred/public_html. Imagine that the webmaster has a CGI script called fido that lives in ... /cgi-bin and belongs to webuser. If the webmaster is wise, she has restricted read and execute permissions for this file to its owner and no one else. This, of course, allows web clients to use it because they also appear as webuser. As things stand, Fred cannot read the file. This is fine, and in line with our security policy of not letting anyone read CGI scripts. This denies them knowledge of any security holes.

Fred now sneakily makes a symbolic link to fido from his own webspace. In itself, this gets him nowhere. The file is as unreadable via symlink as it is in person. But if Fred now logs on to the Web (which he is perfectly entitled to do), accesses his own webspace and then the symlink to fido, he can read it because he now appears to the operating system as webuser.

The `Options` command without `All` or `FollowSymLinks` stops this caper dead. The more trusting webmaster may be willing to concede `FollowSymLinks-IfOwnerMatch` , since that too should prevent access.

Copyright © 2001 O'Reilly & Associates. All rights reserved.